Goal Determination Using Remotely Detected Location in Space and Magnetic Flux-Based Goal-Proximity Sensing

ABSTRACT

A location-and-event-tracking system includes radio-enabled anchors and tags on a field of play, and magnets attached to a goal (e.g., a basketball net). Tags are attached to players and to balls (“game-play objects”), and a magnetometer is embedded within the ball. The system uses the radio-enabled tags to track the position of player and the ball in space, and the system determines whether a basket (i.e., a goal) has been made using both the location of the ball in space and magnetic flux-related data received from the magnetometer. The system also determines whether the ball has gone out of bounds, and it sends a STOP message to the game-clock control system if the ball goes out of bounds or if a shot is made successfully.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to and claims priority under 35 U.S.C. § 119from U.S. provisional patent application No. 62/596,264 filed Dec. 8,2017, the contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to games of sport, and more particularlyto a system that uses remote sensors to track various objects in space(e.g., players, balls, goals, etc.) and identify in “real time” one ormore game-related events as they occur.

BACKGROUND OF THE INVENTION

For most, if not all, sports activities, detailed review and analysis ofhow an individual player and/or a team of players is/are performing iscrucial in order to improve performance. Therefore, tools that enhancethe ability to identify and analyze various events that occur on a fieldof play (e.g., a basketball court, hockey rink, etc.) are desirable.Additionally, it can be difficult for some fans of a fast-paced sport,such as basketball, to see clearly everything that is going on all atonce, given that the games may have many players and the ball (a“game-play object”) all moving simultaneously. Therefore, to the extentthe action of a sporting event can be monitored and analyzed, with theresults of that analysis being displayed for the fans (and even coaches)to see, the fans' enjoyment of a game can be enhanced considerably bysystems and devices that automatically monitor, track, and/or record thelocation and movement of players and objects on the field of play, aswell as the occurrence of certain game-related events.

Furthermore, a system for automatically identifying clock stoppage insporting events has long been needed to assist game officials inaccurately and quickly resetting the time left in the game. For NationalBasketball Association (NBA) games, the rules dictate that the clockmust stop after each made shot during the last 2 minutes of the game.For National Collegiate Athletic Association (NCAA) games, the rulesdictate that the clock must stop after each made shot during the last 1minute of the game. For all levels of organized and timed basketballgames (e.g., NBA, NCAA, high school, junior high school and AmateurAthletic Union basketball), the clock stops whenever the ball isdeclared out of bounds, or whenever a game official calls a foul, atimeout, or a moving violation.

Historically, the procedure for stopping the clock and determining howmuch time is left in a game has been the responsibility of the officialclock operator, oftentimes with assistance from other game officials. Inmore recent years, clock and game officials have resorted to apainstakingly slow process of reviewing video on the sidelines todetermine the exact time to put on the game clock after a clock-stoppingevent. This procedure can easily take several minutes to complete, andoften kills the excitement and momentum of an otherwise exciting,hard-fought and competitive basketball game. When the process of usingvideo to determine the amount of time left in the game takes too long,fans and spectators can become extremely frustrated and have been knownto start jeers and boos at the clock and game officials.

SUMMARY OF THE INVENTION

Embodiments of an installation in accordance with the invention featurea location-and-event-tracking system that includes radio-enabled anchorsand tags on a field of play, e.g., a basketball court. Tags are attachedto the players and the ball(s) or other game-play objects. Additionally,magnets are attached to a goal and a magnetometer is embedded within agame-play object (e.g, a basketball), or vice-versa, and themagnetometer senses magnetic flux emanating from the magnets—i.e., themagnetometer and the magnets interact with each other when they are inthe vicinity of each other. (Generally speaking, the magnets andmagnetometer may be referred to as first and second sensor components.)The system determines and evaluates 1) the location in space of each ofthe tags, including in particular ball-associated tags, and 2) databased on the sensed flux, and the system uses both determinations toassess whether a goal has been made. In particular, if it isdetermined—using tag-based data—that the ball has passed in orderthrough a plurality of predefined discrete sub-regions before, at, andafter the goal, then a goal is identified as having been scored.However, even if the ball is not identified as having passed through allthree sub-regions, a goal is still identified as having been scored ifmagnetic flux-based data indicates that a goal has been scored. Butmagnetic flux-based data will not be considered for purposes ofidentifying whether a goal has been made unless it is determined, usingtag-based location data, that the ball is within a region surroundingthe goal that encompasses the sub-regions before, at, and after thegoal. Once a goal has been identified as having been made, a signal issent to a score-indicating device to cause the score-indicating deviceto indicate that a score has been made. (The score-indicating devicecould be a scoreboard, a computer display, a speaker, or any otherdevice that could be used to inform someone that a goal has been made.)The signal is typically sent to the score-indicating device via aninterface, which may comprise, for example, one or more hardware,software, wired or wireless communication links, including withoutlimitation, an electronic cable connection, a scoreboard control system,a display device controller, an application program interface (API), anetwork adapter interface, a local area network (LAN) interface, awireless interface (such as IEEE 802.11 or Bluetooth®) or anycombination thereof. In this manner, accuracy of the determination as towhether a goal has been scored is improved.

In preferred embodiments, tag-based location data is used to determinewhether the game-play object has gone out of bounds from the field ofplay. If it has, a command is sent automatically to stop the game clock.Additionally or alternatively, a command is sent automatically to stopthe game clock if it is determined that a goal has been made.

Thus, in one aspect, the invention features a method for automaticallyidentifying and indicating on a device whether a goal has been scored ina sporting activity, in which 1) a game-play object (e.g., a basketball)has a remotely identifiable object tag associated with it; and 2) thegame-play object has a first sensor component and the goal has a secondsensor component, which first and second sensor components interact witheach other when the game-play object is in the vicinity of the goal. Themethod includes identifying the position in three-dimensional space ofthe game-play object using its associated tag and obtaining data that isassociated with the first and second sensor components. The identifiedposition of the game-play object is used to assess whether a goal hasbeen made by evaluating whether the game-play object has passed in orderthrough a plurality of predefined discrete sub-regions before, at, andafter the goal, which plurality of sub-regions are within a largerpredefined and limited region surrounding the goal. Additionally, thedata associated with the first and second sensor components is used toassess whether a goal has been made by evaluating interaction betweenthe first and second sensor components. A score is identified based onthe assessment conducted using the identified position of the game-playobject and the assessment conducted using data associated with the firstand second sensor components.

In embodiments, the first and second sensor components include magnetsand a magnetometer disposed on the goal and in the game-play object, andwhether a goal has been scored is assessed using magnetic flux-relateddata. In particular, a peak value of magnetic flux and a summed orintegrated value of magnetic flux may be evaluated to assess whether agoal has been made.

Furthermore, the method may include—using the tag-based position of thegame-play object—determining whether the game-play object is within thelarger predefined and limited region surrounding the goal. The dataassociated with the first and second sensor components is used to assesswhether a goal has been made only if the game-play object is, in fact,within the larger predefined and limited region surrounding the goal.Further still according to the method, a score may be identified ashaving been made, even if the assessment conducted using the identifiedposition of the game-play object indicates that the game-play object haspassed through less than all of the sub-regions before, at, and afterthe goal, if the assessment conducted using data associated with thefirst and second sensor components indicates that a score has been made.

Moreover, the method may include issuing a stop command to stop a gameclock if a score is identified as having been made or if it isdetermined, using the tag-based location data for the game-play object,that the game-play object has gone out of bounds.

In another aspect, the invention features a system for tracking agame-play object on a field of play and for determining whether a goalhas been scored. The system includes an object tag; a first sensorcomponent associated with the game-play object and a second sensorcomponent associated with the goal, which first and second sensorcomponents interact with each other when the game-play object is in thevicinity of the goal; a plurality of sensors which can remotely detectthe object tag; and a computing device having a processor andnon-transitory program instructions contained in computer memorythereof. The non-transitory program instructions are configured to causethe processor to execute the method steps described above, with specificembodiments of the system implementing the various method stepsdescribed above.

The inventive method and system enable highly accurate, wirelesstracking of the location of balls or other game-play objects on a fieldof play, with highly precise determination as to whether a goal has beenscored. Additionally, whether the game-play object has left the field ofplay is determined wirelessly and remotely, and a command isautomatically sent to stop the game clock in that event. A command tostop the game clock is also sent automatically upon determination that agoal has been made, to ensure that the clock stops in those instanceswhere it is required upon scoring a goal. This enhances the ability ofplayers and/or coaches to monitor and evaluate the players'performances, as well as the enjoyment of fans who may be watching theplayers play.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of the invention will become clearer from thedetailed description below as well as the drawings, in which:

FIGS. 1A and 1B are a schematic plan view and side view, respectively,illustrating a location-and-event-tracking installation (at a basketballcourt) for practicing the invention;

FIG. 2 is a diagram illustrating parameters of an object-oriented datastructure representing a basketball court in accordance with theinvention;

FIG. 3 is a side view illustrating various zones around a basketballhoop in accordance with the invention;

FIG. 4 is a diagram illustrating parameters of an object-oriented datastructure representing a basketball player in accordance with theinvention;

FIG. 5 is a diagram illustrating parameters of an object-oriented datastructure representing a basketball in accordance with the invention;

FIG. 6 is a high-level flow diagram illustrating processing of telemetrydata (tag-location or magnetic flux) in accordance with the invention;

FIG. 7 is a flow diagram illustrating processing of tag-location datathat is associated with a player in accordance with the invention;

FIGS. 8A, 8B, and 8C are a flow diagram illustrating processing oftag-location data that is associated with a ball in accordance with theinvention;

FIGS. 9A and 9B are a side view and a plan view, respectively,illustrating a ball-possession-gaining zone and aball-possession-retaining zone around a player;

FIG. 10 is a flow diagram illustrating processing of tag-location datathat is associated with a ball, to identify a player in possession ofthe ball, in accordance with the invention;

FIGS. 11, 12A, and 12B are flow diagrams illustrating processing oftag-location data that is associated with a ball, to identify shotattempts and successful shots, in accordance with the invention;

FIG. 13 is a diagram representing the structure of a time division blockfor radio communications that may be used in one implementation of thepresent invention;

FIG. 14 is a high-level diagram showing the order and direction oftravel for packet transmission in a two-way ranging transaction betweennodes within the network depicted in FIGS. 1A and 1B;

FIGS. 15A and 15B are high-level state diagrams illustrating the variousstates and functions for a tag node and a master anchor node as executedby one implementation of the present invention;

FIG. 16 shows a schematic diagram illustrating some of the informationthat could be transmitted in each type of data transmission packet inone implementation of the present invention;

FIGS. 17A and 17B are high-level flow diagrams illustrating exemplaryalgorithms for data transmission control processes carried out by a tagnode and a master anchor node in one exemplary implementation of thepresent invention;

FIG. 18 is a flow diagram illustrating processing of magnetic flux as itis sensed by a magnetometer embedded within a ball; and

FIG. 19 is a flow diagram illustrating processing of magneticflux-related data that is associated with a ball in accordance with theinvention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

An installation 100 for practicing the invention is illustrated in FIGS.1A and 1B. The installation 100 is implemented, in this case, at abasketball facility that has a playing area (e.g., a basketball court102) and one or more goals (e.g., basketball hoops/baskets) G₁, G₂, . .. G_(n) located at various positions around the court 102, although theinvention could also be implemented in connection with other sports suchas hockey, baseball, football, etc., where the goals could be the hockeynet, baseball bases, the football endzone line, etc. One or more playersP₁, P₂, . . . P_(n) participate in the sporting event, which couldentail multiple players practicing at the same time, as illustrated inFIG. 1A; just a single player practicing by himself or herself, asillustrated in FIG. 1B; or an actual game (not illustrated).

As further illustrated in FIGS. 1A and 1B, a number of ultra-wide-band(UWB) radio-enabled “anchors” are located around the playing area. Theanchors include a “master” anchor A_(M) and a number of “slave” anchorsA_(S1), A_(S2), . . . A_(Sn) positioned at multiple known locationsaround the playing area. The various anchors could be located atapproximately the same level as the players, e.g., by being mounted onpylons or stands that are supported on the court 102, or they could belocated above the field of play, e.g., in the rafters 104 at thesporting facility as illustrated in FIG. 1B.

Additionally, each of the players P₁, P₂, . . . P_(n) wears a UWBradio-enabled tag T₁, T₂, . . . T_(n), respectively, and each of thebasketballs (generically referred to as “game-play objects”) being usedon the court at a given time has a similar UWB radio-enabled tag B₁, B₂,. . . B_(n) located either inside of it or on a surface of it. Thevarious anchors communicate bi-directionally with the various tags andwith each other and, using an associated location-and-event-trackingapplication running on a connected computer, mobile device (smartphone,tablet, laptop computer, etc.), or remote server (i.e., a “connectedcomputing device”) 106, the system can identify the location of each ofthe tags in three-dimensional space. Therefore, because each of the tagsis assigned in the system to a player or a ball, the system candetermine the location in three-dimensional space of each of the playersand balls.

Regarding the computing device 106, it may be connected to the system ofanchors by an Ethernet connection, a USB connection, Wi-Fi, theInternet, or any other suitable mechanism that permits signals to betransmitted between the computing device 106 and the system of anchors.Additionally, in alternative embodiments, thelocation-and-event-tracking application may be stored and executed onone of the various anchors, e.g., the master anchor A_(M).

Such a system of anchors and tags could, for example, be a DWUSB system(http://www.ciholas.com/dwusb), which can be configured to use two-wayradio ranging to monitor and track the location and movements of thevarious basketball players P₁, P₂, . . . P_(n) and the ball(s) B₁, B₂, .. . B_(n) on the basketball court 102, and which is commerciallyavailable from Ciholas Inc. in Newburgh, Ind. Additionally, we havefurther developed the DWUSB system, to better coordinate datacommunications between the various tags and anchors in the system.Particulars of how we have done so are explained in the section entitled“Coordination of Data Communications between Tags and Anchors,” locatedat the end of this Detailed Description.

The system of anchors determines where the various tags are locatedrelative to the various anchors. However, as noted above, the anchorsare positioned at precisely known (i.e., surveyed) positions relative tothe playing field. Therefore, using a straightforward transform, thesystem—in particular, a tracking application that is running on theconnected computing device 106—can determine where the various tags, andhence the players P₁, P₂, . . . P₃ and balls B₁, B₂, . . . B₃, arelocated relative to the playing field.

Pertinent information regarding the playing field, the players, and theballs (i.e., game-play objects) is stored in various object-orienteddata structures 200, 400, and 500, as illustrated in FIGS. 2, 4, and 5.Suitably, the data structures 200, 400, and 500 are located in memory inthe computing device 106 on which the location-and-event-trackingapplication resides and is executed. It is feasible, however, for thedata structures 200, 400, and 500 to be located elsewhere, e.g. on aremote server, with the application retrieving data from and storingdata to the data structures, as necessary, by establishing remoteconnections to the remote server using networks and technologies wellknown in the computer networking field.

As illustrated in FIG. 2, object-oriented data structure 200 representsthe playing field, e.g., the basketball court. For a given court, thedata structure 200 includes an identification number 202 for the court,as well as X and Y coordinates 204 a, 204 b, 206 a, 206 b, 208 a, 208 b,210 a, and 210 b for each of the four corners of the court. To simplifycalculation, it may be desirable for one of the corners of the court tohave X, and Y coordinates of 0,0, with the remaining corners having X,and Y coordinates of X_(max),0; X_(max), Y_(max); and 0, Y_(max), which“places” all positions on the court into the first, completely positivequadrant of a Cartesian coordinate system. Alternatively, the courtcould be configured in the data structure 200 with the origin 0,0 beinglocated in the very middle of the court.

In addition to the court corner locations, the court data structure 200includes an array 212 of hoop data. For each hoop associated with thecourt, the array 212 includes a hoop identification number 214 alongwith the X, Y, and Z coordinates of the center of the hoop in locationdata fields 216, 218, and 220, respectively.

Furthermore, the court data structure 200 includes data for a number ofparameters that define various regions in space surrounding each of thehoops, which parameters enable the location-and-event-trackingapplication to identify attempted baskets (goals); attempted basketsthat have been made successfully; and attempted baskets that have notbeen made successfully, as addressed more fully below. In particular, asillustrated in FIG. 3, a number of regions in space are defined around,above, and below the hoop 302. (FIG. 3 shows the hoop 302 and net 303 inprofile.) These regions in space include an overall goal zone 304, whichis a cylindrical region that has a central, longitudinal axis (notillustrated) that passes through the X-Y center of the hoop 302. Theradius R of the goal zone 304 is set in the ZONE_R_GOAL data field 224,and the vertical extent (width) W of the goal zone 304 is set in theZONE_W_GOAL data field 226. (The size and geometry of the area aroundthe goal may vary by sport—for example, a hockey goal is generallyrectangular—and may be configurable by the users of the system.)Additionally, because the goal zone 304 typically is not centeredvertically relative to the hoop 302, the upper boundary 306 of the goalzone 304 is set in the ZONE_GOAL_ZTOP data field 228, which is thevertical (i.e., Z axis) location of the top of the goal zone 304. Whenit is determined that a ball has entered the goal zone 304, thelocation-and-event-tracking application performs a routine that tracksthe position and trajectory of the ball through space with highprecision to determine whether a basket has been made, as addressed morefully below.

In addition to the goal zone 304, an attempt zone 308, a “make” entryzone 310, a “make” zone 312, and a “make” exit zone 314 are also definedsurrounding, immediately above, immediately at, and immediately belowthe hoop 302, respectively, as illustrated in FIG. 3. Like the goal zone304, the attempt zone 308 is a cylindrical region that has a central,longitudinal axis (not illustrated) that passes through the X-Y centerof the hoop 302. The radius R of the attempt zone 308 is set in theZONE_R_ATTEMPT data field 230, and the vertical extent (width) W of theattempt zone 308 is set in the ZONE_W_ATTEMPT data field 232.Additionally, because the attempt zone 308 typically is not centeredvertically relative to the hoop 302, the upper boundary of the attemptzone 308 is set in the ZONE_ATTEMPT_ZTOP data field 234, which is thevertical (i.e., Z axis) location of the top 309 of the attempt zone 308.

As for the make entry, make, and make exit zones 310, 312, and 314,they, too, are cylindrical regions, with each having a central,longitudinal axis (not illustrated) that passes through the X-Y centerof the hoop 302. The make entry zone 310 “sits” right on top of the hoop302, with its bottom boundary coincident with the vertical position ofthe hoop 302 as specified in the hoop Z location data field 220. Themake entry zone 310 has a radius R, which is slightly larger than theradius of the hoop 302 that is set in the ZONE_R_MAKEENTRY data field236 and a vertical extent (width) W that is set in the ZONE_W_MAKEENTRYdata field 238. The make zone 312 “sits” right under the hoop 302, withits upper boundary coincident with the vertical position of the hoop 302as specified in the hoop Z location data field 220. The make zone 312has a radius R, which is essentially the same as the radius of the hoop302, that is set in the ZONE_R_MAKE data field 240 and a vertical extent(width) W that is set in ZONE_W_MAKE data field 242. The make exit zone314 “sits” right under the make zone 312, with its upper boundarycoincident with the lower boundary of the make zone 312. The make exitzone 314 has a radius R, which is also slightly larger than the radiusof the hoop 302, that is set in the ZONE_R_MAKEEXIT data field 244 and avertical extent (width) W that is set in the ZONE_W_MAKEEXIT data field246. (The radius of the make entry zone 310 and the radius of the makeexit zone 314 are larger than the radius of the hoop 302/make zone 312to account for the fact that balls frequently enter and exit the hoop302 at an angle relative to vertical.)

As further illustrated in FIG. 3, several magnets 316 are attached toeach net 303, and a ball used with the present embodiments (notspecifically illustrated) includes an embedded flux-detectingmagnetometer that measures the strength of a magnetic field to which theball is exposed. (Some exemplary uses of magnetometer-equipped balls, ingeneral, are addressed in U.S. Publication 2017/0144030, the contents ofwhich are incorporated by reference.) Neodymium magnets work well withmost readily available magnetometers, and the magnets 316, which may becylindrical and about a centimeter or two long, may be sewn inside ofthe tubular strands of the net 303. Although just a single magnet mightbe used, in practice ten or twelve magnets distributed around thecircumference of the net have been found to yield better sensingaccuracy.

The magnetometer can be provided as a stand-alone or dedicated,chip-based circuit board, or it can be provided as part of an integratedidentification/acceleration/flux-sensing chip set, both of which areknown in the art. The onboard firmware that controls a ball-associatedtag receives from the magnetometer a flux value and calculates anintegrated (i.e., summed) value of magnetic flux to which the ball isexposed while the flux is above a threshold value, as well as a peakvalue of the magnetic flux. This magnetic flux-related information isthen sent wirelessly by the ball-associated tag, in an ultra-wide-banddata packet, to the anchors, which transmit the data to the computingdevice 106 for further processing. (As addressed more fully below,identifying the position of the ball in three-dimensional space usingthe tags and anchors of the system, and determining that the ball is inthe vicinity of the net by sensing magnetic flux, are adjunct orcomplementary processes implemented by the system; using both increasesoverall accuracy of the system.)

The magnetic-flux process 1800 implemented by the firmware that controlsoperation of a ball-associated tag is illustrated in FIG. 18. Thefirmware executes an ongoing loop with endpoints 1802 and 1804. For eachiteration of the loop, the firmware acquires from the magnetometer themeasured value of magnetic flux (S1806) and sets the current flux valueto be the measured flux value (S1808). Next, the firmware checks whetherthe current flux value exceeds a predetermined starting threshold (stepS1810). If it does not (result path 1812), the firmware loops back toretrieve the next value of magnetic flux to which the ball is beingexposed. (This prevents “background” magnetic noise from beingconsidered.)

On the other hand, if the magnetic flux does exceed the startingthreshold value (result path 1814), values for a flux-recording starttime, maximum flux value, and integrated flux value are set to be thecurrent values (step S1816). The firmware processes each successivevalue of magnetic flux that is received (loop S1818), resetting themaximum flux value to be the current flux value any time the currentflux value exceeds a previously set maximum flux value and calculatingan integral of the flux value by adding each successive flux value tothe previously calculated sum of flux values. The firmware does so aslong as each received value of flux is not less than a predefined endingthreshold value of magnetic flux (result path 1820 from decision stepS1822). (The starting and ending threshold values of magnetic flux donot necessarily have to be the same; suitably, the starting thresholdvalue of magnetic flux is slightly larger than the ending thresholdvalue of magnetic flux, to ensure that magnetic flux is not processedunless it truly is flux that is not just background “noise.”) Once thereceived value of magnetic flux falls back below the ending thresholdvalue of magnetic flux (result path 1824 from decision step S1822),which indicates that the ball is no longer in the vicinity of themagnet-bearing net, the time at which that occurs is set as the end timeTIME_END (S1826); a UWB data packet with the flux-related data istransmitted to the anchors (S1828); and the flux-processing processconcludes (S1830).

Although the magnets are shown on the net and the magnetometer isdescribed as embedded within the ball, the magnet(s) could be locatedwithin the ball and a magnetometer could be attached to the goal. Inthat case, a separate UWB transmitter for the magnetometer would berequired, provided, for example, as one or more tags in or near the netat a point below the rim.

As illustrated in FIG. 4, object-oriented data structure 400 includes,for each player that is in the field of play, a player-identifying IDdata field 402. As noted above, each player wears a radio tag. Thus, thedata in the ID data field 402 is essentially a tag identification numberfor the tag that each player is wearing. Additionally, the datastructure 400 includes, for each player in the field of play, historicinformation as to the player's X location in the LOCATION_X_ARR array(or ring buffer) 404; Y location in the LOCATION_Y_ARR array (or ringbuffer) 406; and Z location in the LOCATION_Z_ARR array (or ring buffer)408. As addressed more fully below, the X, Y, and Z location values areentered into their respective arrays (or buffers) after smoothing, e.g.,using a 10-point moving average, Kalman filter, or other data-smoothingalgorithm. Date and time data corresponding to each players' locationare stored in a LOC_DATETIME_ARR array 410.

Furthermore, the data structure 400 includes fields pertaining towhether a given player is in possession of a basketball. (Determinationof this state is addressed below.) In particular, the BALL data field412 contains the tag ID information for a ball that is determined to bein the player's possession, as addressed below, and the POSSESS_TIMEdata field 414 contains data indicating the length of time for which theplayer is in possession of the ball or is putatively in possession ofthe ball (addressed more fully below). Further still, the CUR_LOC_INDEXdata field 416 is used to keep track of array index locations as theplayer's location data is processed, as described below.

As illustrated in FIG. 5, object-oriented data structure 500 includes,for each ball that may be in the field of play, a ball-identifying IDdata field 502. As noted above, each ball has a radio tag on it orembedded inside it. Thus, the data in the ID data field 502 isessentially a tag identification number for the tag that each ball hasassociated with it. Additionally, the data structure 500 includes, foreach ball in the field of play, historic information as to the ball's Xlocation in the LOCATION_X_ARR array (or ring buffer) 504; Y location inthe LOCATION_Y_ARR array (or ring buffer) 506; and Z location in theLOCATION_Z_ARR array (or ring buffer) 508. As addressed more fullybelow, the X, Y, and Z location values are entered into their respectivearrays (or buffers) after smoothing, e.g., using a 10-point movingaverage, Kalman filter, or other data-smoothing algorithm. Date and timedata corresponding to each of the ball's locations is stored in aLOC_DATETIME_ARR array 510.

Data structure 500 further includes a PLAYER data field 512, whichidentifies a particular player in possession of the ball, as well as aprevious-player data field PREV_PLAYER 514 to keep track of the playerwho last had possession of the ball. The PREV_PLAYER data field 514 isused because no player will be in possession of the ball while it istravelling through the air, e.g., during a shot attempt or as it isbeing passed, during which period of time the player-in-possessionPLAYER data field 512 will be cleared. Therefore, maintaining theprevious-player-in-possession information in the PREV_PLAYER data field514 allows the system to keep track of who took a shot, who passed theball to the next player, or who had the ball stolen away. Additionally,data structure 500 includes a next-player data field NEXT_PLAYER 516,which identifies a player who is close enough to the ball that he or shemight be assigned as having the ball once he or she is determined to beclose enough to the ball for a minimum required possession time, asaddressed more fully below.

Additional fields in the data structure 500 relate to the determinationof whether a basketball shot has been taken and, if so, whether the shothas been made successfully. These fields include an IN_GOAL_ZONE datafield 518, which includes a flag that indicates whether the ball hasentered the goal zone 306, and a DATETIME_GOAL data field, whichidentifies when the ball entered the goal zone for historical, trackingpurposes. Additionally, the HOOP_ID data field 519 identifies theparticular hoop (by hoop ID 214) associated with the goal zone that theball has entered, if any. Data field IN_ATTEMPT_ZONE 522 includes a flagthat indicates whether the ball has entered the attempt zone 308, anddata field IS_ATTEMPT 524 includes a flag that indicates whether theball has entered the attempt zone 308 by virtue of a shot actuallyhaving been taken (i.e., a basket having been attempted) instead ofhappenstance. Data field DATETIME_ATTEMPT 526 includes informationidentifying the date and time when the ball enters the attempt zone 308,for historical, tracking purposes.

Data fields IN_MAKEENTRY_ZONE 528, IN_MAKE_ZONE 530, andIN_MAKEEXIT_ZONE 532 include flags that indicate, respectively, whetherthe ball is successively in the make entry zone 310, the make zone 312,and the make exit zone 314. If it is determined that the ball has passedthrough all three zones (as addressed below) and it is concluded that ashot has been made successfully, then a flag will be stored in theIS_MAKE data field 534 so indicating, and the date and time of the madeshot will be stored in the DATETIME_MAKE data field 536 for historical,tracking purposes. Further still, the CUR_LOC_INDEX data field 538 isused to keep track of array index locations as the ball's location datais processed, as described below.

In general, the location-and-event-tracking application preferably keepstrack of the locations of players and balls on the court using asampling rate of at least 100 Hz, and also tracks each player's shotattempts, made shots, ball possessions, and other motion information forreal-time display and long-term analysis. This data may be madeavailable for long-term analysis and other near-real-time dataprocessing and display by saving all data to the cloud, where it isavailable to a much larger range of devices, including fan-basedapplications.

Operation of the location-and-event-tracking application is illustratedin FIGS. 6-12. As illustrated in the high-level flow diagram 600 of thelocation-and-event-tracking application shown in FIG. 6, the processimplemented by the application begins by receiving telemetry data fromthe player-associated and ball-associated tags in the field of play(S602). This telemetry data includes the X, Y, and Z coordinates of allthe player-associated and ball-associated tags in the field of play,along with associated tag IDs. It also includes, in the case oftelemetry data from ball-associated tags, the flux-related parameters,namely, the integrated value of magnetic flux (MAG_INTEGRAL_VALUE) andthe peak value of magnetic flux (MAG_PEAK_VALUE), as well as a sequenceID (MAG_SEQUENCE) for the flux-related data. The application thendetermines (at step S604) whether the data that has been receivedrepresents a ball (i.e., location data or magnetic flux-related data) ora player (i.e., location data) by comparing the received tag ID topreviously known or configured tag IDs. If the tag is associated with aplayer (result path 608), the program passes the data (location data) toa PROCESS PLAYER module 610 for further processing as described in thenext paragraph and as illustrated by the flow diagram shown in FIG. 7.If, on the other hand, the tag is associated with a ball (result path612), the program passes the data (location data or magneticflux-related data) to a PROCESS BALL module 614 for further processing,as described farther below.

FIG. 7 contains a flow diagram 700, which illustrates the operation ofthe PROCESS PLAYER module 610. As shown in FIG. 7, player-processingbegins at step S702 by retrieving from an internal array, based on theID data field 402, the object representing the particular player beinganalyzed, with the player's X, Y, and Z locations at each point in timebeing stored in the LOCATION_X_ARR array 404, the LOCATION_Y_ARR array406, and the LOCATION_Z_ARR array 408, respectively. For each point intime, the program stores a ten-data-point moving average using theplayer's X, Y, and Z location values for the given point in time and thenine preceding points in time. Thus, the smoothing loop with endpoints704 and 706 is executed ten times, starting with the index for thecurrent point in time and “working backward,” to sum the player'slocation data values for the current point in time and the ninepreceding points in time. The average value for each of the X, Y, and Zlocations is determined by dividing the summed value by ten (S708), andthe averaged value for each of the player's X, Y, and Z locations isthen stored (S710) in memory.

On the other hand, if the telemetry data received at step S602 isassociated with a ball (result path 612), then the program passes theultra-wide-band data (location data or magnetic flux-related data) tothe PROCESS BALL module 614 as noted above. As illustrated in the flowdiagram 800 for the PROCESS BALL module 614 (FIGS. 8A, 8B, 8C, and 19),ball-processing begins by retrieving (S802) from an internal array,based on the ID data field 502, the object representing the particularball being analyzed, with the ball's X, Y, and Z locations at each pointin time being stored in the LOCATION_X_ARR array 504, the LOCATION_Y_ARRarray 506, and the LOCATION_Z_ARR array 508, respectively. Then, themodule evaluates (S860) whether the UWB data that has been received fromthe ball and that is being processed is location data or magneticflux-related data by checking a 2-byte field in the UWB data packet thatdescribes the type of data. If it is not location data—i.e., if the datato be processed is magnetic flux-related data—then the program executesa separate module 862 to process the flux-related data, as illustratedin FIG. 19.

As illustrated in FIG. 19, the magnetic-data-processing subroutine readsin the flux-related data that has been pre-calculated and sent by theball-associated tag, as addressed above (step S1902). Then, as a“check-step” and using the ball's most recent X, Y, and Z location data,the system determines (S1904) whether the ball is within the attemptzone surrounding any of the hoops on the court. (This is done because,depending on the facility where the system is installed, it is possiblefor the magnetometer to detect and record magnetic “noise” in somelocations even when the ball is not near the magnets 316 attached to thenet.) Alternatively, the system could check more broadly for whether theball is in the larger goal zone surrounding the goal. To do so, thesystem implements a loop (not specifically illustrated) in which thesystem retrieves the array 212 for each of the baskets on the court andevaluates whether the horizontal distance between the ball and thecenter of the goal zone 304 associated with the particular hoop (i.e.,SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) is less than the radiusR of the goal zone 304 (ZONE_R_GOAL, 224), and whether the verticalposition Z of the ball is within the vertical range of the goal zone304, i.e., between Z=ZONE_GOAL_ZTOP (228) andZ=(ZONE_GOAL_ZTOP−ZONE_W_GOAL (226)).

If the ball is not located within the goal zone 304 surrounding one ofthe baskets (result path 1906), the process terminates. Otherwise, themagnetometer data is evaluated to assess whether it indicates that abasket has been made successfully. In particular, the sequence ID ischecked (step S1908) to make sure the next timewise-successive set ofmagnetic flux data is being evaluated. Because the magnetometer mostlikely will not be sensing and generating magnetic flux data on aconstant basis, and even when it is generating magnetic flux data it mayor may not be doing so at the same rate as the program is cycling, thischeck ensures that the same flux-related data is not improperlyre-evaluated. If the sequence ID is not the next successive sequence ID(result path 1910), the process terminates. On the other hand, if theintegrated value of the magnetic flux MAG_INTEGRAL_VALUE exceeds apredetermined threshold value THRESHOLD_INTEGRAL (result path 1912), andif the peak value of magnetic flux MAG_PEAK_VALUE that has been detectedfor the particular flux “event” exceeds a predetermined threshold valueTHRESHOLD_PEAK (result path 1914), then a flag IS_MAG_MAKE is set(S1916) indicating that, based on the magnetic flux-related data, abasket has been made successfully; otherwise, if either of thesepredetermined threshold values are not exceeded, the process terminateswithout the flag being set.

On the other hand, with reference back to FIG. 8A, if the UWB data islocation data (result path 864 from decision 860), then the programproceeds to process the location data for the ball. For each point intime, the program stores a ten-data-point moving average using theball's X, Y, and Z location values for the given point in time and thenine preceding points in time. Thus, the smoothing loop with endpoints803 and 804 is executed ten times, starting with the index for thecurrent point in time and “working backward,” to sum the ball's locationdata values for the current point in time and the nine preceding pointsin time. The average value for each of the X, Y, and Z locations isdetermined by dividing the summed value by ten (S806), and the averagedvalue for each of the ball's X, Y, and Z locations is then stored(S808).

Next, the ball is evaluated to determine whether it has gone out ofbounds or whether it remains in play on the court, as illustrated inFIG. 8B. This part of the process begins by evaluating (S866) whetherthe ball's X- and Y-coordinates place it within a bounding rectangledefined by the four corners of the court, which have X- andY-coordinates of X_NE (204 a), Y_NE (204 b), XSE (206 a), YSE (206 b),X_NW (208 a), Y_NW (208 b), XSW (210 a), and Y_SW (210 b). If the cornercoordinates are defined such that one of the corners of the court is atthe origin (0,0) of a cartesian coordinate system and the court isaligned with the cartesian coordinate system, it is simply necessary toevaluate whether the X- and Y-coordinates of the ball fall between themaximum and minimum values of X- and Y-coordinates of the corners of thecourt. Otherwise, whether the ball's X- and Y-coordinates are within thebounding rectangle may be determined using analytical geometry andnumerical methods that are routine in computer graphics processing.

If the ball is determined to be located within the bounding rectangle(result path 868), the IS_OUT_OF_BOUNDS flag is reset to FALSE.Otherwise, if the ball is determined to be outside of the boundingrectangle (result path 870), and if the IS_OUT_OF_BOUNDS flag has notalready been set as determined at decision step S872 (result path 874),then the system evaluates (S876) whether the current Z-coordinate of theball is greater than the previous Z-coordinate of the ball. If it is(result path 878), then the ball is moving upwards. In that case, it isnecessary to determine whether the ball has hit the floor and isbouncing back upwardly. (The ball will not be ruled out of bounds untilit has hit the floor outside of the bounding rectangle.) To do so, theprogram evaluates (decision step S880) whether the previous value of theZ-coordinate of the ball is within a predefined threshold valueBALL_ZERO_Z_THRESHOLD that is consistent with the ball being on theground. Because the tag is embedded inside the ball, this thresholdvalue BALL_ZERO_Z_THRESHOLD is typically not 0 mm; rather, it is a valueslightly less than the diameter of the ball. If the previousZ-coordinate of the ball is within this threshold (result path 882),then the IS_OUT_OF_BOUNDS flag is set to TRUE (S884), and the systemsends a STOP message to the clock control system with an EVENT ofOUTOFBOUNDS (S886).

Depending on the clock control system being used at the particularbasketball facility, the message for STOP may be a formatted data packetcontaining a command to stop the clock; the event associated with theSTOP command, i.e., a shot having been made successfully (furtheraddressed below) or the ball going out of bounds (as addressed above);the exact UTC timestamp when the event occurred; and the UTC timestampwhen the STOP command was sent. The format of the data packet may bedynamically produced to conform to the clock control systemmanufacturer's specifications and could be one of JSON, comma-separatedvalues, or any other format typical in the field of data communications.For example, in JSON format, the STOP command could be issued asfollows:

{   “command” : “STOPCLOCK”,   “event” : “SHOTMADE”   “event_timestamp”: “2017-05-28 16:25:21.123”,   “command_timestamp” : “2017-05-2816:25:21.521” }

After the ball object has been evaluated for being out of bounds, it isevaluated (S810) to see if it already has been assigned to a player bychecking whether the PLAYER property 512 associated with the ball objecthas a value, as illustrated in FIG. 8C. If the PLAYER property 512 has avalue (result path 812), then this indicates either that a player haspossession of the ball, or has just recently had possession of the ball(i.e., at the previous iteration of the overall program loop) but hasgiven it up (e.g., by passing the ball, attempting to make a basket, orhaving had the ball stolen away from him or her). Therefore, if a playeris assigned to the ball object, the system checks (S814) to see whetherthe ball is still near the associated player, so as to distinguishbetween the player still having possession of the ball and the playerhaving just terminated possession of the ball.

In this regard, as illustrated in FIGS. 9A and 9B, the zone around agiven player in which the player may be considered to be gainingpossession of the ball (subscript “P” in the figures) is slightlysmaller than the zone around the player in which the player will beconsidered to be retaining possession of the ball (subscript “R” in thefigures), given that a player will typically pull the ball in close totheir body when receiving the ball, then may move the ball farther awayfrom their body as they attempt to pass, shoot, or hold the ball awayfrom an opposing player. Thus, the horizontal radius of thereceiving-possession zone R_(P) around the player is smaller than thehorizontal radius of the retaining-possession zone R_(R) around theplayer. Similarly, the height of the receiving-possession zone Z_(P) isless than the height of the retaining-possession zone Z_(R). (Theacceptable ranges of horizontal radius and height for a ball to be neara player may be configurable parameters that vary by sport and age groupof players using the system. In some embodiments for basketball,examples of acceptable ranges are 4 feet in radius and 8 feet inheight.)

Therefore, to determine whether the ball is still near the associatedplayer (S814), the system determines how far away from the associatedplayer the ball is in the horizontal direction by calculating the squareroot of the sum of the squares of the difference between the ball's andthe player's X coordinates and the difference between the ball's and theplayer's Y coordinates(SQRT((X_(ball)−X_(player))̂2+(Y_(ball)−Y_(player))̂2)). If the horizontaldistance between the ball and the associated player is less than orequal to the larger, retaining-possession radius R_(R), and the Zcoordinate of the ball is less than or equal to the larger Z value ofthe retaining-possession zone height Z_(R), then the previouslyassociated player will be considered to be still in possession of theball (result path 816), and the system stores the location of the ball(S818) locally or to a server in the cloud for long term storage anddistribution to connected applications.

If it is determined (S814) that the ball is not near the previouslyassociated player (result path 820), then the association between theball and the player is cleared at S822 (PLAYER attribute 512 of the ballobject and BALL attribute 412 of the player object are both nullified)on the assumption that the player has passed the ball, shot the ball, orhad the ball stolen away, and the process returns (return path 823).Additionally, before nullifying the association, the PREV_PLAYER datafield 514 will be set to the identity of the player who has just had andlost possession of the ball. Furthermore, to prepare the data registersto identify the next player that comes into possession of the ball, thenext-player data field NEXT_PLAYER 516 is also cleared.

If, on the other hand, the result of the evaluation S810 to see whetherthe ball is associated with a player is negative (result path 824), thesystem checks (S826) to see whether a value has been assigned to thenext-player data field NEXT_PLAYER 516, which will be the case ifpossession processing (described shortly below) has identified a playerthat is close enough to the ball to at least possibly be the next playerto take possession of the ball. (The next-player that is so identifiedwill not be associated with the ball as actually having possession untila predetermined amount of time has elapsed, as detailed below.) If anext-player value has, in fact, been assigned to the ball in thenext-player data field NEXT_PLAYER 516 (result path 828), the systemwill check (S830) to see whether the ball is near enough to the nextplayer to “hold” the next player as potentially the next player to takeactual possession of the ball.

For this evaluation (S830), the system uses the radius and heightdimensions of the smaller, gaining-possession zone around a playerillustrated in FIGS. 9A and 9B. Thus, the system checks to see whetherthe horizontal distance between the ball and the identified next player(SQRT((X_(ball)−X_(next-player))̂2+(Y_(ball)−Y_(next-player))̂2)) is lessthan or equal to the smaller, gaining-possession radius R_(P) and the Zcoordinate of the ball is less than or equal to the smaller Z value ofthe gaining-possession zone height Z_(P). If the ball is, in fact, nearenough to the next player to satisfy these conditions (result path 832),then the system counts how long the ball is near the next player, i.e.,by incrementing (S834) the possession time data field POSSESS_TIME 414for the next player by the amount of time between successive iterationsof the processing loop, e.g., 0.01 seconds for the case where the systemexecutes at a rate of 100 Hz. So long as the next player maintainspossession of the ball within the receiving-possession zone, anotherincrement of time will be added (S834) to the accumulated possessiontime data field POSSESS_TIME 414 for the next player each time theoverall process is implemented, until it is determined (S836) that theaccumulated possession time exceeds the predetermined minimum amount ofpossession time (e.g., on the order of one-half to one second, which maybe set depending on the skill level of the players in connection withwhom it is expected the system will be used). When this happens, theplayer that has been being “held” as the putative next player isassigned to be the player who is actually in possession of the ball. Inparticular, the player data field PLAYER 512 associated with the ballobject is given the player ID value 402 of the player who has been thenext player (S838), and the ball data field BALL 412 associated with theobject for the player who was being held as the next player—now theplayer actually in possession of the ball—is given the ball ID value 502of the ball to indicate that that player now has possession of the ball.Additionally, the next-player data field NEXT_PLAYER 516, which has“served its purpose,” is cleared.

If, on the other hand, the ball is not (yet) within thegaining-possession zone around the next player (result path 840 fromdetermination S830), then the next-player data field NEXT_PLAYER 516associated with the ball object is cleared (S843), as is any possessiontime that may have accumulated in the possession-time data fieldPOSSESS_TIME 414 for the player being “held” as next-player, e.g., at aprior iteration of step S834 while the ball was “just passing through”the gaining-possession zone. As addressed more fully below, a player isidentified as the putative next player to have possession of the ball bya possession-determining subroutine 842, which operates based on closestproximity to the ball. Therefore, assuming the previously identifiedplayer is still closest to the ball on the next iteration of theprogram, the same player will again be identified as the putative nextplayer to have possession, and this will keep happening until the ballenters the gaining-possession zone around the next player (at whichpoint in time the next player will begin accruing possession time) oruntil the ball has passed completely out of the gaining-possession zonein the case where the ball was merely moving through the player'sgaining-possession zone without the player actually taking possession ofthe ball.

As further illustrated in the flow diagram 800 (FIG. 8C), if no playeris associated with the ball and 1) a next player has not been assignedto the ball (result path 844 from evaluation step S826), i.e., the ballhas not come close enough to another player for another player to beidentified as the potential next player to possess the ball; or 2) theball was only briefly near a next player but no longer is (result path840/841 from evaluation step S830), then the ball will be somewhere infree space. Additionally, even if a player has had possession of theball right up until the point in time that he or she makes a basket,e.g., in the case of a dunk or a layup, it will also be the case that noplayer is associated with the ball and a next-player will not have beenassigned to the ball in the moments right after the basket has beenmade. Therefore, in this case (no player is assigned to the ball;next-player is not assigned to the ball; and ball is not near thenext-player), the system will need to process the ball to identify thenext player who will be, or is, in possession of the ball, or todetermine whether the ball has been shot toward or taken to the basketand, if so, whether a basket has been made successfully.

To start this process, the system determines (S846) whether the ball iswithin the goal zone 304 surrounding any of the hoops on the court.(Even when a player has had possession of the ball right up until thepoint of making the basket, the system operates fast enough that theball will still be located within the goal zone 304, in the momentsafter the basket has been made, for the system to detect the ball'scurrent location and trigger this part of the process.) To do so, thesystem implements a loop (not specifically illustrated) in which thesystem retrieves the array 212 for each of the baskets on the court andevaluates whether the horizontal distance between the ball and thecenter of the goal zone 304 associated with the particular hoop (i.e.,SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) is less than the radiusR of the goal zone 304 (ZONE_R_GOAL, 224), and whether the verticalposition Z of the ball is within the vertical range of the goal zone304, i.e., between Z=ZONE_GOAL_ZTOP (228) andZ=(ZONE_GOAL_ZTOP−ZONE_W_GOAL (226)). If the ball is, in fact, locatedwithin the goal zone 304 surrounding one of the baskets (result path848), the HOOP_ID data field 519 is set (S850) to reflect theso-identified hoop whose surrounding goal zone 304 the ball has entered,and the program then invokes a subroutine 852 to evaluate whether abasket has been attempted (and, if so, whether a basket has been madesuccessfully), as addressed more fully farther below. Otherwise, if theball is not located within the goal zone 304 surrounding one of thehoops (result path 854), the HOOP_ID data field 519 is cleared (S856) ofany residual value, and the program invokes the possession-determiningsubroutine 842 alluded to above, as addressed immediately below.

Operation of the possession-determining subroutine 842 is illustrated bymeans of the flow diagram 1000 shown in FIG. 10. In general, thesubroutine identifies the player who is closest to the ball and, if thatplayer is close enough to the ball to actually have it, assigns theclosest player to the ball as presumptively being the next player to bein possession of it. As explained above, actual possession of the ballis not established unless and until the ball is near the putativenext-player for a predetermined minimum amount of time (S836). Untilthat happens, the ball's associated NEXT_PLAYER parameter (516) will becleared out (S843) before the possession-determining subroutine 842 isinvoked. Thus, the subroutine begins by initializing variables (S1002)in order to determine the distance between the ball and the closestplayer and to be able to keep track of the distance between the ball andall of the various players' tags. In particular, the player who ispresumptively the next player to possess the ball is initially set to beunidentified (NEXT_PLAYER (516)=NULL) and is assumed to be at aradial-distance tolerance (MIN_R=TOL_R) and a vertical-distancetolerance (MIN_Z=TOL_Z) away from the ball, which tolerances are maximumvalues at what a player conceivably could be in possession of the ball.Suitably, the tolerance values may be the same as thehorizontal-distance and vertical-distance values that are used to assessproximity of the ball to the players, for determining whether a playerhas gained possession of the ball or retained possession of the ball asdescribed above.

Next, the system enters a loop with end-points 1004, 1006 that evaluateseach player in sequence (S1008) to determine which player, if any, isclosest to the ball and within the maximum permitted tolerance. For eachiteration of the loop, the system calculates the horizontal distance Rbetween a given player and the ball(R=SQRT((X_(ball)−X_(player))̂2+(Y_(ball)−Y_(player))̂2) and the verticaldistance between the given player and the ball (DZ=Z_(ball)−Z_(player)).If the values for horizontal distance and vertical distance are bothless than the corresponding values for the previously considered player(or the initialized values on the first pass through the loop) (resultpath 1010), then the player under consideration during the giveniteration of the loop is considered to be the player who is closest to,and therefore presumptively next to be in possession of, the ball. Inthat case, the parameters are updated (S1012) to set the new minimumdistances equal to the distances between the ball and the player underconsideration (MIN_R=R, MIN_Z=DZ) and to presumptively assign to theball, as the next player to be in possession of the ball (NEXT_PLAYER(516)=PLAYER_ARRAY[INDEX]), the player under consideration. Otherwise(result path 1014), the process simply circles back to the beginning ofthe loop (1004) to evaluate the next player in the array of players.Furthermore, if no player is found to be less than the tolerance valuesof horizontal and vertical distance away from the ball, no next-playervalue (NEXT_PLAYER (516)) will be assigned to the ball.

As explained above, result path 844 (from evaluation step S826) andresult path 840/841 (from evaluation step S830) will be followed whenthe ball is in free space, e.g., being passed from one player to anotheror on its way toward a basket. Additionally, as noted above, result path844 will be followed as soon as a player who has had possession of theball right up until the point of making a basket no longer haspossession. Therefore, whether the ball is in the goal zone 304surrounding one of the baskets on the court is evaluated at evaluationstep S846, as addressed above. If the ball is not within a goal zone,the next player to get possession of the ball is determined via thepossession-determining subroutine 842 as addressed above. Otherwise, ifthe ball is, in fact, within one of the goal zones 304 (result path 848from evaluation step S846), the program sets the HOOP_ID data field 519associated with the ball object to identify the hoop in proximity towhich the ball is located and then invokes the attempt-identifyingsubroutine 852, as alluded to above.

Operation of the attempt-identifying and shot-made subroutine 852 isillustrated in greater detail in the flow diagrams 1100 and 1200 shownin FIGS. 11 and 12A/12B, respectively. In particular, the process startsby confirming (S1102) that the ball's X, Y, and Z coordinates place itwithin the region of the goal zone 304 surrounding the hoop identifiedin step S846. If the ball is not, in fact, within this zone, then theprogram clears all ball properties in the ball object pertaining to theposition of the ball vis-à-vis the basket (S1104) and returns to thecalling process (S1106). Otherwise, if the ball is, in fact, within thegoal zone area around the identified basket, then the system sets theball property IN_GOAL_ZONE 518 to true (S1108).

“Narrowing down” the focus of the analysis, the ball's X, Y, and Zcoordinates are next evaluated (S1110) to determine whether the ball isin the attempt zone 308. (As is the case with respect to the goal zone304, the system operates fast enough that the ball will still be locatedwithin the attempt zone 308, in the moments after the basket has beenmade, for those cases where the player had possession of the ball rightup until the point in time the based has been made.) This is done byassessing whether the horizontal distance from the ball's X-Y locationto the X-Y center of the hoop(SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) is less than or equalto the radius of the attempt zone (ZONE_R_ATTEMPT, 230) and whether theZ position of the ball is somewhere in the range descending from theattempt zone top 309 (ZONE_ATTEMPT_ZTOP, 234) downward by an amountequal to the attempt zone height/width (ZONE_W_ATTEMPT, 232). If theball is, in fact, in the attempt zone 308 (result path 1111), theIN_ATTEMPT_ZONE flag 522 and the IS_ATTEMPT flag 524 are both set toTRUE (S1112) and the process returns (S1106).

If the ball is not in the attempt zone 308 (result path 1113), thatcould be the result of either 1) the shot having been missed (e.g.,bouncing off of the hoop 302 and out of the attempt zone 308 or missingthe attempt zone 308 completely) or 2) the shot having been madesuccessfully and passing out of the attempt zone 308 via the threemake-related zones (make entry zone 310, make zone 312, and make exitzone 314). Therefore, if the ball is not in the attempt zone 308 whenbeing checked at step S1110, the process checks (S1114) whether theIN_ATTEMPT_ZONE flag 522 has been set (i.e., is true), which wouldindicate that the ball was in the attempt zone 308 on the previousiteration of the process. If the IN_ATTEMPT_ZONE flag 522 has not beenset (result 1116), the process returns (S1106). However, if theIN_ATTEMPT_ZONE flag 522 has, in fact, been set, the PROCESS BALLLOCATIONS subroutine 1120 is invoked. This subroutine cycles through theball's preceding locations, in reverse chronological order over the lastfew second (e.g. four seconds), to determine whether the ball hastraveled a path through space that took it through the hoop—in effect,whether a basket has been made successfully.

As illustrated by the flow diagram 1200 shown in FIGS. 12A and 12B, thePROCESS BALL LOCATIONS subroutine begins (S1202) by setting a loopiterator to the index of the previous location of the ball, i.e., thelocation just prior to the ball no longer being in the attempt zone 308.Next, a ball-locating loop with endpoints 1204, 1206 begins evaluatingeach preceding ball location in reverse order, essentially following thepath of the ball backwards as it (potentially) passes through thevarious zones around and adjacent to the hoop 303.

The first evaluation (S1208) in the loop tests whether the ball'slocation—starting with the location just prior to the location-trackingsubroutine 1120 being invoked—is within the attempt zone 308 using thesame calculations as for step S1110. (For the first pass through thesubroutine 1120, this will be true.) If the ball's location for a givenpreceding point in time is not in the attempt zone 308 (result path1210)—i.e., the given preceding point in time is the point in time justprior to the ball entering the attempt zone 308—then the loop 1204/1206terminates.

Otherwise, if the ball's location for the given preceding point in timeis (still) in the attempt zone 308, the process checks (S1212) whetherthe ball's location is in the make exit zone 314. More particularly, thesystem checks whether the horizontal distance between the ball and thecenter of the make exit zone 314(SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) was less than theradius R of the make exit zone 314 (ZONE_R_MAKEEXIT, 244), and whetherthe ball was within the vertical range between the top of the make exitzone 314/bottom of the make zone 312 (Z=Z_(hoop) (220)—ZONE_W_MAKE(242)) and the bottom of the make exit zone 314 (Z=Z_(hoop)(220)—(ZONE_W_MAKE (242)+ZONE_W_MAKEEXIT (246)). If the ball's locationfor the given preceding point in time was in the make exit zone 314(result path 1214), the IN_MAKEEXIT_ZONE flag 532 is set to true (S1216)and the loop continues (path 1218) to consider the next-preceding balllocation.

On the other hand, if it is determined at step S1212 that the ball'slocation at the given preceding point in time was not in the make exitzone 314 (result path 1220), the same location is tested (S1222) todetermine whether it was within the make zone 312. In particular, thesystem checks whether the horizontal distance between the ball and thecenter of the make zone 312(SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) was less than theradius R of the make zone 312 (ZONE_R_MAKE, 240), and whether the ballwas within the vertical range between the top of the make zone 312(Z=Z_(hoop) (220)) and the bottom of the make zone 312 (Z=Z_(hoop)(220)−ZONE_W_MAKE (242)). If the location was in the make zone 312(result path 1224), then the processes further checks (S1226) whetherthe IN_MAKEEXIT_ZONE flag 532 has been set to TRUE (on a previousiteration of the loop). If the IN_MAKEEXIT_ZONE flag 532 has been set toTRUE (result path 1228), then this indicates that the path of the ballhas carried it from the make zone 312 directly into the make exit zone314, in which case the IN_MAKE_ZONE flag (530) is set to TRUE (S1230)and the loop continues (path 1232) to consider the next-preceding balllocation. Otherwise, if the IN_MAKEEXIT_ZONE flag 532 has not been setto TRUE (result path 1234), the loop continues to consider thenext-preceding ball location without the IN_MAKE_ZONE flag (530) havingbeen set to TRUE.

Further still, if it is determined at step S1212 that the ball'slocation at the given preceding point in time was not in the make exitzone 314 (result path 1220), and it is also determined at step S1222that the ball's location at the given preceding point in time was not inthe make zone 312 (result path 1236), then the process proceeds todetermine (S1238) whether the ball's location at the given precedingpoint in time was within the make entry zone 310. In particular, thesystem checks whether the horizontal distance between the ball and thecenter of the make entry zone 310(SQRT((X_(ball)−X_(hoop))̂2+(Y_(ball)−Y_(hoop))̂2)) was less than theradius R of the make zone entry 310 (ZONE_R_MAKEENTRY, 236), and whetherthe ball was within the vertical range between the top of the make entryzone 310 (Z=Z_(hoop) (220)+ZONE_W_MAKEENTRY (238)) and the bottom of themake entry zone 310, i.e, the hoop location (Z=Z_(hoop) (220)). If thegiven preceding location was in the make entry zone 310 (result path1240), then the processes further checks (S1242) whether theIN_MAKE_ZONE flag 530 has been set to TRUE (on a previous iteration ofthe loop). If the IN_MAKE_ZONE flag 530 has been set to TRUE (resultpath 1244), then this indicates that the path of the ball has carried itfrom the make entry zone 310 directly into the make zone 312, in whichcase the IN_MAKEENTRY_ZONE flag (528) is set to TRUE (S1246) and theloop continues (path 1248) to consider the next-preceding ball location.Otherwise, if the IN_MAKE_ZONE flag 530 has not been set to TRUE (resultpath 1250), the loop continues to consider the next-preceding balllocation without the IN_MAKEENTRY_ZONE flag (528) having been set toTRUE.

This process of setting the iterator ITER to the next previous balllocation and testing the location against the various make zones inreverse chronological order continues until the preceding ball locationwas no longer in the overarching attempt zone 308 at all, therebyeffectively testing whether the trajectory of the ball passes throughall three of the hoop “make” zones in sequential order. In other words,the process determines whether a shot has been made successfully, and itis robust enough to identify those situations in which a player hastaken the ball to the basket (dunk or layup) to make the basket.

After the loop is completed, the process checks (S1252) whether allthree “make” flags (IN_MAKEENTRY_ZONE (528), IN_MAKE_ZONE (530), andIN_MAKEEXIT_ZONE (532)) have been set to TRUE. If all three flags havebeen set to TRUE, then the path of the ball was through the hoop—i.e.,the shot was successful—and the IS_MAKE flag (534) is set to TRUE andthe time at which the shot was made is set to be the current system time(S1254).

On the other hand, even if not all three “make” flags IN_MAKEENTRY_ZONE,IN_MAKE_ZONE, and IN_MAKEEXIT_ZONE have been set to TRUE (result path1256), as a “cross-check” or “adjunct” to the tag location-baseddetermination as to whether a basket has been made, the process checks(S1258) whether the magnetometer-based telemetry indicates that a shothas been made successfully, i.e., whether the IS_MAG_MAKE flag is TRUE.If the IS_MAG_MAKE flag is, in fact, TRUE despite the fact that not allthree tag location-based flags IN_MAKEENTRY_ZONE, IN_MAKE_ZONE, andIN_MAKEEXIT_ZONE have been set to TRUE (result path 1260), then theIS_MAKE flag (534) will still be set to TRUE and the time at which theshot was made will still be set to be the current system time (S1254).In this regard, it should be recognized that the magnetometer-basedinquiry does not function as a complete or unlimited “override” of thelocation-based determination as to whether a shot has been madesuccessfully. This is because, as addressed above with respect to FIG.19, the magnetometer data is not even processed if the ball is notlocated within the goal zone surrounding one of the baskets (result path1906) as determined using the tag location-based data.

If the IS_MAKE flag has been set to TRUE (result path 1262 of decisionstep S1264), then the fact that a shot has been attempted and madesuccessfully is stored in local memory counters, on disk, and/or in thecloud and sent to the cloud or emitted as a data communication packet,e.g., a UDP data packet, for local or remote “listeners” (includingclock or score management systems) (step S1266). Additionally, thesystem will send a STOP message to the clock control system with anEVENT of SHOTMADE (S1268), and the MAKE flags will be reset to FALSE(S1270). (It is assumed that the clock control system will check theamount of time remaining in the game before acting on the STOP messageand stopping the game clock, since the clock does not stop upon making ashot until the last one or two minutes remaining in the game (NCAA andNBA, respectively) as noted above.) On the other hand, if the IS_MAKEflag has not be set to TRUE (result path 1272 of decision step S1264),then the fact that a shot has been attempted but missed is stored inlocal memory counters, on disk, and/or in the cloud and sent to thecloud or emitted as a data communication packet, e.g., a UDP datapacket, for local or remote “listeners” (including clock or scoremanagement systems) (step S1274).

The ball-processing subroutine 614 (flow diagram 800) then returns theIS_ATTEMP flag (524) and the IS_MAKE flag (524) to the overall program,and the statistics for the last player to have been in possession of theball prior to the shot being taken can be updated accordingly (notillustrated).

Coordination of Data Communications Between Tags and Anchors

As noted at the outset of this description, we have improved upon thedata transmission timing protocols typically found in ananchor/tag-based location-tracking system, in order to avoid“collisions” between simultaneously broadcast signals within a givenchannel. Toward that end, the improved date transmission methodologyprovides devices and methods for coordinating data transmissions amongthe anchors and tags (generically referred to as nodes) in the datacommunications network by precise scheduling and continual management oftransmission time intervals for each anchor or tag. The master anchorspecifies discreet transmission time intervals, termed reserved timeslots, for each node. The reserved time slots are subdivisions of largertime intervals, termed windows, which are themselves subdivisions oflarger blocks of time, called time division blocks. As tags are added tothe network, each tag is assigned a reserved time slot in which toexchange transaction packets with the master anchor. The master anchoris configured to detect and process transaction packets broadcast by thetags during their reserved slots of time, and in turn transmitadditional timing instructions back to each tag, if necessary, to ensurethat each tag's data transmission activity continues to occur within itsreserved time slot.

The time division blocks, which are defined by the master anchor,include a configuration window and at least one transaction window.During the configuration window of the time division block, the masteranchor detects and processes configuration request packets broadcast bynew tags wishing to join the network and start exchanging data with themaster anchor. In response to receiving a configuration request from anew tag during the configuration window, the master anchor establishes areserved time slot within the transaction window for the new tag, andthen broadcasts a configuration response packet to the tag, whichprovides the reserved time slot to the tag, along with specificoperating parameters for the tag to follow, including an initial timedelay for the tag to wait before making its first attempt to broadcast aset of transaction packets. The master anchor may detect and admitmultiple tags to the network during the configuration window, therebyestablishing reserved time slots and initial time delays for all of theadmitted tags. During the transaction window, when the reserved timeslot for a particular tag arrives, the master anchor detects andprocesses the set of transaction packets broadcast by that particulartag.

This approach to coordinating the various data transmission isillustrated in FIGS. 13-17B.

In implementations of the system as illustrated above, the master anchorA_(M) measures and divides the passage of time into a continuous streamof adjacent time division blocks. FIG. 13 shows an example of a timedivision block 1300 as may be defined by the master anchor A_(M) inimplementations of the system. Each time division block 1300 spans afixed length of time, such as 50 milliseconds long. It is understood bythose in the art, however, that time division blocks of shorter orlonger intervals may be used, depending on the number, type andtransmission speeds of the tags used in the wireless data communicationsnetwork. When the length of the time division block is defined to be 50milliseconds long, then the network repetition cycle is 20 Hz (i.e.,each second comprises 20 consecutive time division blocks). If the timedivision block 1300 is too large, then the master anchor A_(M) will notbe able to receive and process consecutive signals from rapidly-movingtags fast enough to track their current locations in real time. If thetime division block 1300 is too small, then it will not have sufficientroom to reserve time slots for a large number of tags.

As shown in FIG. 13, the time division block 1300 comprises threeseparate subdivisions of time, including a configuration window 1305, atransaction window 1310, and a slave window 1315. The configurationwindow 1305, which is reserved for configuration functions, such asdetecting and admitting new tags, lasts 20 ms, and is further dividedinto discrete time slots 1320 to 1325, during which configuration datapackets are exchanged.

The transaction window 1310 lasts 20 ms, and is further subdivided intofifteen reserved time slots 1330 to 1335, during which the master anchorA_(M) receives and processes transaction packets broadcasted by tagsoperating in the wireless data communications network. All of thetransactions between the master anchor A_(M) and tags occur within thesereserved slots 1330 to 1335. This partition of the transaction window1310 can accommodate data packet exchanges with up to 15 tags.Optionally, the system can also allocate a third segment of time calledthe slave window 1315, which lasts 10 ms. Within slave window 1315,signals from up to 2 slave anchors A_(S(n)) can be exchanged duringreserved time slots 1340 and 1345.

As noted above, the wireless sensor installation 100 that can beemployed with the invention utilizes two-way communication and rangingand is illustrated in FIGS. 1A and 1B. More particularly, the systememploys a particular two-way ranging method called “snooping,” in whichthe player tags P_((n)) and the basketball tags B_((n)) exchange datapackets directly with the master anchor A_(M), and the slave anchorsA_(S(n)) simultaneously listen for the data transmissions emanating fromthe player tags P_((n)) and the ball tags B_((n)). The slave anchorsA_(S(n)) transmit their own data packets to the master anchor A_(M)during the slave window 1315 of time division block 1300 shown in FIG.13. This additional snooping data from the slave anchors A_(S(n)) isthen used by the computer 106 connected to the master anchor A_(M) inthe wireless sensor installation 100 to calculate the locations of theplayers and the balls as described above.

The master anchor A_(M) can be its own transponder, acting as a gatewaynode through which the computer 106 can access the wireless sensorinstallation 100, or it could be incorporated directly into the computer106. In one implementation, the computer 106 connected to master anchorA_(M) may be configured to apply well understood ranging techniques,such as two-way ranging, to determine the locations of the variousplayer tags and ball tags in real-time. This is achieved by the computer106 continuously processing information conveyed in the exchange of datapackets between each active node joined to the wireless sensorinstallation 100 during each time segment of the time division block1300 shown previously in FIG. 13. The tags will perform their rangingfunctions during their reserved time slots within reserved time slots1330 to 1335 of the transaction window 1310, and the slave anchorsA_(S(n)) will transmit their data during their reserved time slotswithin the reserved time slots 1340 and 1345 of slave window 1315, asdepicted previously in FIG. 13.

FIG. 14 shows a typical ranging transaction between two nodes at point Aand point B. If the clocks in the nodes at points A and B were perfectlyin sync with each other, then a single packet would suffice for thelocalization calculations. However, even though modern electronics arevery close in terms of clock rates (to within millionths of a second),they can never achieve absolutely perfect synchronization, and initiallyslight discrepancies between the clocks multiply over time, causing theclocks in the separate nodes to drift farther and farther apart fromeach other. Due to this fact, each node in the installation 100 isassumed to have its own time domain. Three packets are exchanged betweenthe nodes at points A and B, with a timestamp relative to each node'stime domain generated by each unique transmission event and receptionevent (i.e., six timestamps). The node at point A initiates, and thenode at point B calculates. In the implementation of the two-way rangingsystem shown in FIGS. 1A and 1B, the data rides as a data payload on thelast packet sent. This ranging data piggybacks on packets withoutcompromising arrival times of the signals.

While the wireless sensor installation 100 will function adequately withonly two anchors, namely, a master anchor A_(M) and a single slaveanchor A_(S), additional slave anchors A_(S(n)) may be added to thenetwork to increase the precision and fidelity of the location data andto avoid problems that might arise, for example, when a direct line ofsight between a tag and one anchor is obstructed by a person or objecton the court.

FIG. 15A shows a state diagram for an active tag—e.g., a ball tagB_((n)) or a player tag P_((n))—as used with the invention. Following apower-on or reset state 1500, the tag first enters an initializationstate 1505, in which the parameters defined by the firmware within thetag's electronic chip are initialized. The tag next enters aconfiguration request state 1510, in which the tag broadcasts aconfiguration request to announce its presence to the network and torequest operating instructions from the master anchor A_(M). Next, thetag will enter a listening state 1515, in which the tag listens for aresponse from the master anchor A_(M) to its configuration request. Ifno response is received while the tag is in the listening state 1515,then the tag will reduce its power consumption and enter a sleepingstate 1520 for a randomly assigned time period of between one and threeseconds before reawakening and returning to the initialization state1505. Although the tags can be potentially disruptive in the event ofsignal collisions within a channel until the tag's beacon falls withinthe configuration window, the configuration request signal is extremelyshort, thereby minimizing any potential for signal jamming or data loss.

If the tag receives a configuration response containing operatinginstructions from the master anchor A_(M) while it is in the listeningstate 1515, then the tag next enters an operational state 1525, in whichthe tag processes configuration parameters provided by the master anchorA_(M). One such configuration parameter comprises an initial delayperiod that the tag should wait before beginning to broadcasttransaction packets to the master anchor A_(M). The tag next enters awaiting state 1530 for a period of time equal to the initial delayperiod, during which the tag reduces its power consumption and sleeps.When the initial delay period has expired, the tag enters a transactionstate 1535. In one implementation, the tag exchanges transactionpackets, such as ranging packets, with the master anchor A_(M) duringthe transaction state 1535. However, the installation 100 may beconfigured to exchange any other types of data during the transactionwindow, and not just ranging data. Following the first exchange oftransaction packets, the tag moves back into the waiting state 1530, andwaits for the next reserved time slot in the next transaction window ofthe next time division block before returning again to the transactionstate 1535.

As the tag moves through states 1505, 1510, 1515, and 1520, the packetsexchanged with the master anchor A_(M) include a configuration request,a configuration response, and a configuration acknowledgment. In oneimplementation, the configuration window is approximately 500microseconds long. Configuration packet exchanges are only initiated bytags that have not yet been configured, and the master anchor A_(M) willonly respond to a configuration request if it hears the configurationrequest within 600 microseconds of the end of the configuration window,thus preventing configuration packet exchanges from interrupting ordelaying tag or slave anchor A_(S(n)) packet exchanges. If theconfiguration-initiating tag hears the configuration response within 1.5ms of sending a configuration request, it will respond with aconfiguration acknowledgment packet, and then schedule a rangingtransaction so that it occurs during the reserved time slot of thetransaction window. If the initiating tag does not hear a responsewithin 1.5 ms, then it will enter the sleep state 1520 for a randomamount of time (typically between one and three seconds) beforeattempting to send another configuration request.

The configuration response transmitted by the master anchor A_(M)contains the initial delay period that the tag should wait beforeattempting to broadcast a two-way ranging transaction to the masteranchor A_(M). The configuration response also contains the tag'stransmission period, the network ID (used when multiple networks areavailable) and the network timeout. The network timeout tells the taghow many consecutive times the device should attempt to communicate withthe master anchor A_(M) without receiving a response from the masteranchor A_(M). The data contained in each configuration packet in oneimplementation of the system is discussed in greater detail below withreference to FIG. 16.

In exemplary implementations of the network that use two-way ranging todetermine tag location, the data packets exchanged with the masteranchor A_(M) while a given tag is in transaction state 1535 may includea two-way ranging request, a two-way ranging response, and a two-wayranging acknowledgment. It takes approximately 5 ms for a tag to wake upfrom a sleeping state. In the exemplary implementation, a tagtransaction is approximately 1 millisecond in length. If a tag has morethan 10 ms before its next scheduled transaction (twice the amount oftime it takes for the tag to wake up), then it will sleep untilapproximately 5 ms before its next transmission, and then wake up intime to be ready to transmit during its reserved time slot 1330 to 1335shown previously in FIG. 13. Therefore, if the time division block is 50ms, and the transaction packet exchange lasts for 1 ms, then the tagwill sleep for approximately 44 ms of each time division block. At thescheduled transaction time, the tag sends a transaction packet, such asa two-way ranging request, to the master anchor A_(M). In preferredembodiments, the tag uses the period it received from the master anchorA_(M) in its last communication with the master anchor A_(M) in order toschedule the next tag transaction, which reduces the drift that mightotherwise occur if the tag's clock moves at a rate that is slightlydifferent from the rate of the master anchor's clock.

When the master anchor A_(M) receives a two-way ranging request, itgenerates a two-way ranging response. This response contains the delaythat the tag should wait before sending the next two-way rangingrequest, the period value, and other network data. If the tag receives atwo-way ranging response from the master anchor A_(M), then it willrespond with a two-way ranging acknowledgment packet and update itsscheduled tag transaction time with the adjusted delay received in thetwo-way ranging response. If the tag does not receive a two-way rangingresponse within 1.5 ms, then it will use the period last assigned by themaster anchor A_(M) to determine the next transaction time. At the endof the two-way ranging transaction, or after the reception timeoutexpires, the tag returns to a low power sleep state. The data containedwithin each type of transaction packet used by one implementation of thenetwork is discussed in greater detail below with reference to FIG. 16.

FIG. 15B shows a state diagram for the master anchor A_(M) as used by anexemplary implementation of the installation 100. As shown in FIG. 15B,the master anchor A_(M) cycles through three separate phases ofoperation, corresponding to the three windows in the time divisionblock, beginning with a configuration phase 1540, in which the masteranchor A_(M) detects configuration request packets broadcast by any newtags that are not already member of the master anchor's datacommunications network and wish to be added to the network. This isfollowed by a transaction phase 1560, during which the master anchorA_(M) and tags exchange transaction packets. Finally, the master anchorA_(M) enters the slave phase 1580, during which the master anchor A_(M)exchanges two-way ranging data packets with the slave anchors A_(S(n)).

In the configuration phase 1540, which corresponds to the configurationwindow 1305 of FIG. 13, the master anchor A_(M) moves through severaldistinct states. The master anchor A_(M) first listens for anyconfiguration requests broadcasted by new tags attempting to join thenetwork (configuration listening state 1545). Upon detection of aconfiguration request from a new tag not yet joined to the network, themaster anchor A_(M) will move to a configuration response state 1550, inwhich the configuration parameters specific to the new tag are assembledand transmitted back to the tag. This is followed by a finalconfiguration acknowledgment state 1555, where the master anchor A_(M)attempts to receive and process a confirmation message from the new tagconfirming that the new tag has successfully received and processed theconfiguration parameters transmitted by the master anchor A_(M). Themaster anchor A_(M) then returns to the listen state 1545.

In this manner, the master anchor A_(M) receives and processesconfiguration requests and sends configuration parameters back to thetags, relaying to the tags crucial operating parameters such as theirrepeat rate, when the tags will begin transmitting relative to when eachtag entered network, where in the transaction window the tag's reservedtime slot falls, and when to transmit transaction packets relative toeach tag's time domain. The master anchor A_(M) may also be configuredto tell the tag how long it should wait to receive responses from themaster anchor A_(M) before timing out (network timeout parameter), aswell as how many times to repeat a configuration request before the tagassumes that no network is available and shuts down.

Within the transaction phase 1560, which corresponds to the transactionwindow 1310 shown previously in FIG. 13, the master anchor A_(M)exchanges transaction packets in a sequential manner with each of thetags currently joined to the network, first listening for transmissionsfrom the tags in tag listening state 1565, then receiving and analyzingtransaction packets from the tag in receiving state 1570, and finallyprocessing transaction packets in the transaction processing state 1575.The master anchor A_(M) has the ability to determine how accurately eachtag transmits within its reserved time slot by analyzing transmissiontime stamps upon receipt and comparing this information to the list ofreserved time slots, entering an adjustment state 1597, as necessary, toaccount for any drifting toward the boundaries of the reserved timeslot. Details of the operation of the master anchor A_(M) during theadjustment state 1597 are discussed in greater detail below withreference to FIG. 17B.

Within the slave transaction phase 1580, which corresponds to the slavewindow 1315 shown previously in FIG. 13, the master anchor A_(M)exchanges data packets with the slave anchors A_(S(n)). First the masteranchor A_(M) listens for transmissions from slave anchors A_(S(n)) inslave listening state 1585. Then the master anchor A_(M) receivestransmitted signals from the slave anchors A_(S(n)) during receivingstate 1590. Finally, the master anchor A_(M) processes the snooping datadiscussed above during the slave data processing 1590. In one exemplaryimplementation, the slave data packet exchange includes a two-wayranging request, a two-way ranging response, and a two-way rangingacknowledgment between a slave anchor A_(S(n)) and a master anchorA_(M). A slave transaction may be approximately 3 milliseconds inlength. Slave transactions are similar to tag transactions, except thatslave anchors A_(S(n)) do not sleep, and the final packet of a slavetransaction is a two-way ranging acknowledgment packet, on which thesnoop data piggybacks as additional payload.

For the purpose of scheduling, the master anchor A_(M) may beconfigured, in some implementations, to first sort the list of tags andanchors A_(S(n)) in the network by device type and repeat rate. The tagsare placed in the list first, and are then sorted by their repeat ratessuch that lower repeat rates are scheduled first in the transactionwindow. All devices are then assigned transaction numbers and phases.Time slots in the transaction window are reserved and assigned to tagsbased upon their repeat rate settings. In one implementation of thenetwork, if a tag's repeat rate setting is such that it does not performtwo-way ranging during every time division block 1300 (shown in FIG.13), then that tag may be instructed by the master anchor A_(M) to sharea reserved time slot with one or more other tags that do not requireexchanging two-way ranging packets during every time division block1300. For example, if two tags are sharing a reserved time slot, theneach tag will transmit transaction packets in alternating fashion, everyother time the reserved time slot occurs. If the repeat rate settingcorresponds to a repeat rate of 20 Hz, which is equal to 50 millisecondsper each cycle (the magnitude of the time division block 1300), thenthat tag is expected to transmit transaction packets every single timethat the reserved time slot occurs and does not share that time slotwith any other device. In this manner, the 15 tag transaction slots arefilled. Slave anchors A_(S(n)) are assigned time slots in the order theyare received from the master anchor A_(M). The slave anchors A_(S(n))are always configured so that their repeat rate is equivalent to thelength of the time division block (50 milliseconds).

FIG. 16 shows the order of fields in each packet for each type of datatransmission packet exchanged between the nodes of on exemplaryimplementation of the installation 100. As shown in FIG. 16, there aresix types of data transmission packets used in the configuration andtransaction events during operation of the system.

The configuration request packet 1601 contains data in binary form,beginning with an identification of the packet type 1600, informationabout the packet version 1602, and the network ID 1604, which would beneeded if multiple wireless data communications networks are operatingin close proximity to each other. The configuration request packet 1601also carries the broadcast address 1606, and the specific serial number1608 for the tag sending the configuration request packet 1601. Thisserial number is unique to each tag manufactured of a particular model,and is included so that the system can recognize what data protocolswill be needed for the successful exchange of data. A final element ofconfiguration request packet 1601 is a sequence number 1610, which is anarbitrary number that increments for each transmission, providing aparticular number for every event during the operation of the system.

The configuration response packet 1603 also contains a field 1612 thatidentifies the type of packet, followed by the packet version field1614, and the network ID field 1616. The serial number field 1618 willbe the same serial number used in field 1608 of the configurationrequest packet 1601 and serves to confirm that the master istransmitting a configuration response packet 1603 meant for the specifictag that transmitted the configuration request packet 1601. Alsocontained in the configuration response packet 1603 is the masteraddress field 1620, a sequence number field 1622, and a destinationaddress field 1624. Field 1624 contains the device configuration datafor that particular tag or slave anchor A_(S(n)). Field 1628 containsthe delay time in milliseconds, which tells the tag how long it shouldwait until beginning its first data transaction, and field 1630 containsthe period in milliseconds, which tells the tag how long to wait torepeat its transmission relative to its own time domain. The last field1632 in the configuration response packet 1603 contains the time outparameter, which tells the tag how long it should wait if no response isreceived from the master anchor A_(M) during the transaction window.Fields 1612-1622 are considered to be the “header” data forconfiguration packet 1603, while fields 1624-1632 are considered tocarry the “payload.”

The configuration acknowledge packet 1605 contains the packet type field1634, the packet version field 1636, the network ID field 1638, themaster address field 1640, which will be the same data used in themaster address field 1620 of the configuration response packet 1603. Thetag address field 1642 will have the same data as the destinationaddress field 1624 from the configuration response packet 1603, whichensures that the tag and master anchor A_(M) transmit to one anotherduring each packet transaction. A sequence number field 1644 completesthe configuration acknowledge packet 1605.

The two-way ranging request packet 1607, two-way ranging response packet1609, and the two-way ranging acknowledgment packet 1611 are exchangedby the master anchor A_(M) and tags during the transaction windows. Thetwo-way ranging request packet 1607 contains the packet type field 1646,the packet version field 1648, the network ID field 1650, and the masteraddress field 1652, followed by the tag address field 1654. Next is thetwo-way ranging ID field 1656, which is an identifier unique to thatparticular two-way ranging transaction. The sequence number field 1658follows, and the transmission time field 1660 completes the two-wayranging request packet 1607.

The two-way ranging response packet 1609 contains the packet type field1662, the packet version field 1664, the network ID field 1666, and thetag address field 1668, which carries the same information as the tagaddress field 1654 of the two-way ranging request packet 1607. Themaster address field 1670 contains the same information as the masteraddress field 1652 of the two-way ranging request packet 1607. Next isthe two-way ranging ID field 1672, which contains the same identifier asthe two-way ranging ID field 1656 of the two-way ranging request packet1607. The sequence number is contained in field 1674, the delayparameter field 1676, and the transmission period is provided in field1678. In the two-way ranging response packet 1609, the delay field 1676and period field 1678 are the payload and serve as a means of adjustingthe start of the tag transmissions during each two-way rangingtransaction to ensure that each tag continues to transmit during itsreserved slot.

The two-way ranging acknowledgment packet 1611 contains the packet typefield 1680, the packet version field 1682, the network ID field 1684,and the master address field 1686, which carries the same information asthe master address field 1670 of the two-way ranging response packet1609. The data contained in the tag address field 1688 is the sameinformation as the data in tag address field 1668 of the two-way rangingresponse packet 1609. The two-way ranging ID field 1690 follows, and itcontains the same identifier as the two-way ranging ID field 1672 of thetwo-way ranging response packet 1609. The sequence number is containedin field 1692. The final two fields of the two-way rangingacknowledgment packet 1611 are the receive time field 1694 and thetransmit time field 1696, which are used to calculate the tag'sposition.

Other data can be piggybacked to the transaction packets as additionalpayload, such as biometric information, tag status information, tagbattery health, and any other information useful to the system tomaintain optimal network performance or to populate an array or databasefor use as supplementary event analysis.

FIG. 17A shows a flow diagram detailing the actions performed by a tagin one exemplary implementation of the installation 100. The tag firstbecomes active at the power on or reset step 1700. The tag enters theconfiguration state at step 1705 in which it announces its presence tothe network. Upon detection by the network, the tag transmits aconfiguration request 1710, receives a configuration response 1715, andtransmits a configuration acknowledgment 1720. If, after transmittingthe configuration request in step 1710, no configuration response isdetected at step 1715, the tag returns to the configuration step 1705and again attempts to announce itself to the network. If the tag doesreceive a configuration response in step 1715, information from theconfiguration response and acknowledge packets are used by the scheduler1725 to direct the two-way ranging actions 1730 of transmit, receive,and transmit. If, during the two-way ranging actions of step 1730, thetag comes to a point where it does not receive a signal from the masteranchor A_(M), the tag will enter the time out step 1735, which causesthe tag to go back to the configuration step 1705.

In one implementation of the network, the configuration response datapacket provides a network timeout parameter to the tag (see field 1632in FIG. 16). This timeout tells the tag how long it should wait for aresponse from the master anchor A_(M) before timing out. Alternately,each time a tag sends a transaction request, a variable denoting thenumber of times the tag attempted the request timeouts is incremented.Upon the reception of a transaction response, the device resets theattempt counter to zero. Should the attempt counter exceed thepredefined threshold, then the tag will drop off the network and beginrequesting a new configuration.

FIG. 17B shows a flow diagram detailing the actions performed by themaster anchor A_(M) in one exemplary implementation of the installation100. During the configuration window, the master anchor A_(M) receives aconfiguration request at step 1740, and determines at step 1745 that theconfiguration request came from a new tag. At step 1750, the masteranchor A_(M) assigns a new reserved time slot for the tags'transactions. Information relating to the slot assignment is recorded ina tag state array 1755. During the transaction window, the master anchorA_(M) receives a two-way ranging request from one tag (step 1765),transmits a two-way ranging response at step 1770, and receives atwo-way ranging acknowledgment at step 1775. Transmission timeinformation relating to the two-way ranging request received in step1765 is recorded in the tag state array 1755. The tag state array isaccessed by the adjuster 1760, which continually monitors thetransmission time performance of the tags to determine how accuratelyeach tag transmits packets within its reserved time slot. The adjusterincorporates time adjustment parameters into the transmission of the twoway ranging response 1770 when required. The master anchor A_(M) mayalso update the tags' delay periods to ensure timely transaction packettransmissions. If the master anchor A_(M) does not receive a two-wayranging request during the transaction window, the master anchor A_(M)then proceeds to a time out step 1780, during which it may clear the tagstate array.

The delay period shown in FIG. 17A for a device's first two-way rangingtime (ttwr) is calculated when a configuration request packet isreceived by the master anchor A_(M). Referring back to FIG. 13, if therequest originates from a tag, then the first delay is equal to the timeremaining in the configuration window 1305, plus the time from the startof the transaction window 1310 to that device's reserved transactionslot, which refers to the ordering of transactions within a window, asopposed to the timing of transactions, plus 50000 microsecondsmultiplied by the number of time division blocks 1300 that pass beforethe specific transaction. The calculation for a slave anchor A_(S(n)) isessentially the time remaining in the configuration window 1305, plusthe length of the transaction window 1310, plus the time from the startof the slave window 1315 to its data packet transaction.

When the transaction response packet is assembled, the system may beconfigured to include a tag period setting for the tag so that the tagwill know when to attempt to retransmit its payload data (should packetsbe dropped during the first attempt). When the master anchor A_(M)receives a transaction packet from the tag, the master anchor A_(M)calculates an adjusted tag period for the tag using the followingformula:

t _(adjust)=mod(t _(transaction) ,t _(block))−mod(t _(rx) ,t _(block)),

-   -   where,    -   t_(adjust) is the adjusted tag period,    -   t_(transaction) is the expected time of receiving the        transaction packet,    -   t_(block) is the duration of the time division block, and    -   t_(rx) is the time the packet was actually received.

Tag period setting values correspond to the number of time divisionblocks between data packet transactions. A tag period setting of 0 isthus 20 Hz, and a tag period setting of 1 is 10 Hz. The tag's next timeto start a two-way ranging transaction (ttwr) is determined bymultiplying the number of time division blocks by 50000 microseconds(the size of the time division block). The adjusted tag period (tadjust)is added to the start of the next two-way ranging transaction (ttwr)before it is sent to the tag. The number of blocks until the nexttwo-way ranging transaction is determined by the phase and the tagperiod setting of the master anchor A_(M). The current phase, relativeto the requesting tag, is the current time on the master device dividedby 50000, modulo the tag period setting for the tag.

The scheduling algorithm of the implementation coordinates thetransmission of a plurality of tags joined to a wireless datacommunications network. Because the nodes each have their own timedomains, which are subject to drift relative to each other and to thenetwork, the present solution imposes a precise time scheme for thenodes to take action within a distributed system. The system candetermine slot transmission performance with a tolerance of +/−10microseconds, which is sufficient precision to enable the system toprocess a plurality of data packet transactions with near 100% use ofavailable channel capacity. This centralized scheduling approach savesbattery life at the nodes by having them follow designated time periods,saving power when the node is not transmitting, as radio frequencytransmissions can be costly in terms of power used. The wholearchitecture is biased to save battery power at tags, and only needs tocalculate adjustment at one place in the network. Therefore, the tagsare not required to take any more actions than are necessary.

The foregoing disclosure is only intended to be exemplary of the methodsand products of the present invention. Departures from and modificationsto the disclosed embodiments may occur to those having skill in the art.The scope of the invention is set forth in the following claims.

We claim:
 1. A method for automatically identifying and indicating on adevice whether a goal has been scored in a sporting activity, wherein 1)a game-play object that is manipulated within a field of play and usedto score by being passed through a goal has a remotely identifiableobject tag associated therewith; and 2) the game-play object has a firstsensor component and the goal has a second sensor component, which firstand second sensor components interact with each other when the game-playobject is in the vicinity of the goal, the method comprising:identifying a position in three-dimensional space of the game-playobject using its associated tag; obtaining data that is associated withthe first and second sensor components; using the identified position ofthe game-play object, assessing whether a goal has been made byevaluating whether the game-play object has passed in order through aplurality of predefined discrete sub-regions before, at, and after thegoal, which plurality of sub-regions are within a larger predefined andlimited region surrounding the goal; using the data associated with thefirst and second sensor components, assessing whether a goal has beenmade by evaluating interaction between the first and second sensorcomponents; identifying whether a score has been made based on theassessment conducted using the identified position of the game-playobject and the assessment conducted using data associated with the firstand second sensor components; and transmitting a signal to the device tocause the device to indicate that a score has been made.
 2. The methodof claim 1, wherein the object tag includes a radio-enabled transceiverand wherein a plurality of radio-enabled anchor transceivers aredistributed around the field of play at known locations, and wherein theposition in three-dimensional space of the game-play object isidentified using radio communication between the object tag and theanchor transceivers.
 3. The method of claim 1, wherein the first andsecond sensor components comprise a magnetometer and magnets, whichmagnetometer senses magnetic flux emanating from the magnets andgenerates magnetic flux data.
 4. The method of claim 3, wherein themagnetic flux data generated by the magnetometer is used to produce saiddata associated with the first and second sensor components.
 5. Themethod of claim 4, wherein the flux data generated by the magnetometeris used to produce said data associated with the first and second sensorcomponents only if the magnetic flux sensed by the magnetometer reachesor exceeds a first predetermined threshold flux value.
 6. The method ofclaim 5, wherein the flux data generated by the magnetometer stops beingused to produce said data associated with the first and second sensorcomponents if the magnetic flux sensed by the magnetometer falls to orbelow a second predetermined threshold flux value.
 7. The method ofclaim 6, wherein the second predetermined threshold flux value is lessthan the first predetermined threshold flux value.
 8. The method ofclaim 4, wherein said data associated with the first and second sensorcomponents comprises a peak value of sensed magnetic flux and a summedor integrated value of sensed magnetic flux.
 9. The method of claim 8,wherein a score is identified as having been made only if the peak valueof sensed magnetic flux and the summed or integrated value of sensedmagnetic flux meet or exceed respective predetermined threshold values.10. The method of claim 1, further comprising using the position of thegame-play object identified using the associated tag, determiningwhether the game-play object is within said larger predefined andlimited region surrounding the goal, wherein the data associated withthe first and second sensor components is used to assess whether a goalhas been made only if the game-play object is within said largerpredefined and limited region surrounding the goal.
 11. The method ofclaim 1, wherein a score is identified as having been made, even if saidassessment conducted using the identified position of the game-playobject indicates that the game-play object has passed through less thanall of said sub-regions before, at, and after the goal, if saidassessment conducted using data associated with the first and secondsensor components indicates that a score has been made.
 12. The methodof claim 1, further comprising issuing a stop command to stop a gameclock if a score is identified as having been made.
 13. The method ofclaim 1, further comprising using the identified position of thegame-play object, assessing whether the game-play object has gone out ofbounds of the field of play; and if the game-play object has gone out ofbounds of the field of play, issuing a stop command to stop a gameclock.
 14. A system for tracking a game-play object on a field of playincluding at least one goal and for automatically identifying andindicating on a score-indicating device whether a score has been made,the system comprising: an interface to the score-indicating device; anobject tag associated with the game-play object; a first sensorcomponent associated with the game-play object and a second sensorcomponent associated with the goal, which first and second sensorcomponents interact with each other when the game-play object is in thevicinity of the goal; a plurality of sensors which can remotely detectthe object tag; and a computing device having a processor, a computermemory, and non-transitory program instructions in the computer memory;wherein the non-transitory program instructions are configured to causethe processor to execute the steps comprising receiving data from theplurality of tag-detecting sensors; obtaining data that is associatedwith the first and second sensor components; identifying from the datareceived from the tag-detecting sensors a position in three-dimensionalspace of the game-play object; using the identified position of thegame-play object, assessing whether a goal has been made by evaluatingwhether the game-play object has passed in order through a plurality ofpredefined discrete sub-regions before, at, and after the goal, whichplurality of sub-regions are within a larger predefined and delimitedregion surrounding the goal; using the data associated with the firstand second sensor components, assessing whether a goal has been made byevaluating interaction between the first and second sensor components;identifying whether a score has been made based on the assessmentconducted using the identified position of the game-play object and theassessment conducted using data associated with the first and secondsensor components; and transmitting a signal to the score-indicatingdevice via the interface to cause the score-indicating device toindicate that a score has been made.
 15. The system of claim 14, whereinthe object tag includes a radio-enabled transceiver and the plurality ofsensors include radio-enabled transceivers, which can communicateelectronically with the object tag; and wherein the position inthree-dimensional space of the game-play object is identified usingradio communication between the object-tag transceiver and the sensortransceivers.
 16. The system of claim 14, wherein the first and secondsensor components comprise a magnetometer and magnets, whichmagnetometer senses magnetic flux emanating from the magnets andgenerates magnetic flux data.
 17. The system of claim 16, wherein theflux data generated by the magnetometer is used to produce said dataassociated with the first and second sensor components.
 18. The systemof claim 17, wherein the non-transitory program instructions areconfigured such that the flux data generated by the magnetometer is usedto produce said data associated with the first and second sensorcomponents only if the magnetic flux sensed by the magnetometer reachesor exceeds a first predetermined threshold flux value.
 19. The system ofclaim 18, wherein the non-transitory program instructions are configuredsuch that the flux data generated by the magnetometer stops being usedto produce said data associated with the first and second sensorcomponents if the magnetic flux sensed by the magnetometer falls to orbelow a second predetermined threshold flux value.
 20. The system ofclaim 19, wherein the non-transitory program instructions are configuredsuch that the second predetermined threshold flux value is less than thefirst predetermined threshold flux value.
 21. The system of claim 17,wherein the non-transitory program instructions are configured such thatsaid data associated with the first and second sensor componentscomprises a peak value of sensed magnetic flux and a summed orintegrated value of sensed magnetic flux.
 22. The system of claim 21,wherein the non-transitory program instructions are configured such thata score is identified as having been made only if the peak value ofsensed magnetic flux and the summed or integrated value of sensedmagnetic flux meet or exceed respective predetermined threshold values.23. The system of claim 14, wherein the non-transitory programinstructions are configured to cause the processor to 1) determinewhether the game-play object is within said larger predefined andlimited region surrounding the goal using the position of the game-playobject identified using the associated tag, and 2) assess whether a goalhas been made using the data associated with the first and second sensorcomponents only if the game-play object is within said larger predefinedand limited region surrounding the goal.
 24. The system of claim 14,wherein the non-transitory program instructions are configured such thata score is identified as having been made, even if said assessmentconducted using the identified position of the game-play objectindicates that the game-play object has passed through less than all ofsaid sub-regions before, at, and after the goal, if said assessmentconducted using data associated with the first and second sensorcomponents indicates that a score has been made.
 25. The system of claim14, wherein the non-transitory program instructions are furtherconfigured to cause a stop command to be issued to stop a game clock ifa score is identified as having been made.
 26. The system of claim 14,wherein the non-transitory program instructions are configured such thatwhether the game-play object has gone out of bounds of the field of playis assessed using the identified position of the game-play object; and astop command to stop a game clock is issued if the game-play object hasgone out of bounds of the field of play.